Memory leak or exception access violation

Please look over the code snippet below and let me know what is causing my execution error(s). I am using Doors 9.0. I can generally run this once through ok, but if I execute it again I get a out-of-memory dump. Other times it won't execute once through without giving me a diagnostic log saying I hit an unrecoverable error. FYI, when it does run ok the total output file size is < 120k.

The intent of this is to produce a list of all database 'items' that Projects, Folders, or Formal modules, in this format:
/MyProject1Name,Project
/MyProject1Name/MyFolder1,Folder
/MyProject1Name/MyFolder1/MyFormalModuleName,Formal
/MyProject1Name/MyFolder1/MyFormalModuleName2,Formal,1.0 BaselineSuffix
/MyProject2Name,Project
...

The stack dump from the unrecoverable error I get says stuff like this (I'm not sure normal would look like):

DOORS: DOORS: 81 percent of memory is in use.
DOORS: There are 2097151 total Kbytes of physical memory.
DOORS: There are 738472 free Kbytes of physical memory.
DOORS: There are 4159628 total Kbytes of paging file.
DOORS: There are 1005224 free Kbytes of paging file.
DOORS: There are 1fff80 total Kbytes of virtual memory.
DOORS: There are 3db6c free Kbytes of virtual memory.

 

 

Stream out = write("h:\\output.txt") // network drive
Buffer BufGetItemsInProject = create(120000)
 
void getAllItemsInDB()
{
    Project myProj
    Item I
    BufGetItemsInProject = ""
    Baseline bline
    Module m
    
    for myProj in database do
    {
        if (!isDeleted(myProj))
        {
            BufGetItemsInProject = rootName_(myProj) ",Project\n"
            for I in myProj do
            {
                if (type(I) == "Project")
                {
                    break
                }
                if (type(I) == "Folder" or type(I) == "Formal")
                {
                    BufGetItemsInProject += rootName_(I) "," type(I)
                    if (type(I) == "Formal")
                    {
                        m = read(rootName_(I), false)
                        if (m != null)
                        {
                            bline = getMostRecentBaseline(m)
                            if (bline != null)
                            {
                                BufGetItemsInProject += "," (major bline) "." (minor bline) " " (suffix bline)
                            }
                        }
                    }
                    BufGetItemsInProject += "\n"
                }
            }
            out << tempStringOf(BufGetItemsInProject)
            flush(out)
        }
    }
}
 
getAllItemsInDb()
flush(out)
close(out)
delete(BufGetItemsInProject)

 

 


Rob_S - Mon Mar 05 11:57:29 EST 2012

Re: Memory leak or exception access violation
Mathias Mamsch - Mon Mar 05 17:18:15 EST 2012

Well maybe you should try closing the modules for starters, see if it helps :-) regards, Mathias
 

if (type(I) == "Formal") {
   m = read(rootName_(I), false)  // Where do you close them?
   if (m != null) {
      bline = getMostRecentBaseline(m)
      if (bline != null) { BufGetItemsInProject += "," (major bline) "." (minor bline) " " (suffix bline) }
   }
}

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

Re: Memory leak or exception access violation
Rob_S - Tue Mar 06 08:35:52 EST 2012

Thanks Mathias. I am new to dxl and have read many of your posts. I'm very happy you answered me. I wish there was some sort of Best Practices doc that would explain the basics above what the DXL Help does. Oh well. Anyway you nailed it. Changing the code above as seen below solves my problems. I needed to close the module and additionally I had to change the read to use a fullName instead of rootName_. I'm not sure why but it was causing an exception at times.
 

m = read(fullName(I), false)
if (m != null)
{
    bline = getMostRecentBaseline(m)
    if (bline != null)
    {
        BufGetItemsInProject += "," (major bline) "." (minor bline) " " (suffix bline)
    }
    close(m)
}

 


Is there a way to check if a module is already open instead of opening/closing it each iteration? I'm trying to optimize this and am wondering if it takes much time to perform the read.

Thanks!

 

Re: Memory leak or exception access violation
llandale - Tue Mar 06 19:18:38 EST 2012

Rob_S - Tue Mar 06 08:35:52 EST 2012

Thanks Mathias. I am new to dxl and have read many of your posts. I'm very happy you answered me. I wish there was some sort of Best Practices doc that would explain the basics above what the DXL Help does. Oh well. Anyway you nailed it. Changing the code above as seen below solves my problems. I needed to close the module and additionally I had to change the read to use a fullName instead of rootName_. I'm not sure why but it was causing an exception at times.
 

m = read(fullName(I), false)
if (m != null)
{
    bline = getMostRecentBaseline(m)
    if (bline != null)
    {
        BufGetItemsInProject += "," (major bline) "." (minor bline) " " (suffix bline)
    }
    close(m)
}

 


Is there a way to check if a module is already open instead of opening/closing it each iteration? I'm trying to optimize this and am wondering if it takes much time to perform the read.

Thanks!

 

Issuing a read takes no time if its already open, unless you open it Visibly when its currently Invisible. so "read" is satisfactory for getting an open module's Handle.

  • bool AlreadyOpen = (!null Module module(I))
  • ...
  • if (!AlreadyOpen) close(mod)
I suggest you get into the habbit of routinely opening the standard view when opening modules; if nothing else it saves time, and the default view can sometimes wreak havok with unpleasant layouts and filtering.
  • m = read(fullName(I), false, true)

Since top level folders and all project names must be unique, the 'fullName' (which traces back to the project) and the 'rootName_' should both work equally well. I cannot think of a compelling reason to use fullName but that's what I do all the time, excepting when I'm trying to tell somebody the rootName_ of a project.

-Louie

Re: Memory leak or exception access violation
Rob_S - Tue Mar 13 14:53:18 EDT 2012

Thank you for this information.